Summary

Adds useAction to @solana/react: a generic React hook that bridges any async function into a tracked action by wrapping createReactiveActionStore from @solana/subscribable. The hook is the React-side adapter for the existing framework-agnostic state machine — store is created once, the user's fn is held in a layout-effect-synced ref so the latest closure is invoked on every send(...) (no deps array), state is consumed via useSyncExternalStore, and the store is reset() on unmount to abort any in-flight call. The shape (status + data + error + derived is* booleans + stable send / reset) matches the supersede-on-second-call / stale-while-revalidate semantics already encoded in the underlying store.

Good, well-scoped PR. Nice docblocks and a thorough test suite covering all four state transitions, supersede semantics, SWR data preservation, fresh-closure capture, and reference stability of send/reset. Changeset is present and well-written; the tsconfig.json ESNext.Promise → ES2024.Promise narrowing is appropriate (Promise.withResolvers landed in ES2024 and the tests rely on it). README placement under the foundational-hooks section before ## Hooks (wallet hooks) reads consistently with the existing layout.

Things to watch / discussion points

Nothing blocking — the points below are suggestions worth a glance:

1. Store creation via useMemo([]) — React technically reserves the right to discard useMemo caches; the canonical "create once, never re-create" pattern for store-like objects is const [store] = useState(() => createReactiveActionStore(...)) (or useRef with lazy init). In practice this doesn't bite today, but useState makes the lifetime guarantee explicit and is what zustand, jotai, etc. use for the same situation. Inline comment with more detail.

2. useLayoutEffect and SSR — useLayoutEffect emits the well-known no-op-on-server warning under React SSR. This package builds a Node entrypoint and useSyncExternalStore itself is SSR-safe, so consumers may render this in an SSR shell. The common workaround is const useIsoLayoutEffect = typeof window !== 'undefined' ? useLayoutEffect : useEffect. Worth confirming whether @solana/react considers SSR a target.

3. Ref-staleness during the layout-effect window — the latest-fn ref is assigned in useLayoutEffect, which means a send(...) invoked from a child component's layout effect (which runs before the parent's) could still see the previous fn. Vanishingly unlikely in practice, and TanStack/wagmi have the same edge — flagging only for awareness.

For subsequent reviewers

• Verify the useLayoutEffect choice against whatever SSR posture @solana/react targets — if SSR is supported, swap for the typeof window guarded variant.
• Sanity-check the assumption baked into the silenced react-hooks/refs: it relies on createReactiveActionStore only invoking its callback inside dispatch/dispatchAsync, never during construction or getState. That matches the current implementation in packages/subscribable/src/reactive-action-store.ts, so the rule suppression is sound — but it's an invariant worth keeping in mind if that store ever gains eager behavior.
• The keeps stable send / reset references test passes trivially today because both come straight off the store, which is created with [] deps. If point (1) above changes the construction strategy, that test still holds.

Re-review

Would approve if I had repo write access — GitHub blocks APPROVE reviews from accounts without explicit access, so leaving this as a comment.

All three points from the prior review are addressed:

1. Store lifetime — useMemo([]) → useState(() => createReactiveActionStore(...)). Lifetime is now an explicit React guarantee rather than a best-effort cache.
2. SSR safety — useIsomorphicLayoutEffect shim added with a clear inline comment explaining why falling back to useEffect on the server is functionally equivalent (no event handlers can fire during SSR, so the ref-sync timing doesn't matter there).
3. Typetest — the trivial result.error satisfies unknown was dropped; the remaining assertions (ActionResult<...> shape, send(7) satisfies Promise<string>, data satisfies string | undefined) are all meaningful.

The eslint-disable react-hooks/refs suppression on the useState initializer is correct: fnRef.current is only read inside the dispatchAsync body in createReactiveActionStore, never at construction or during getState, so the rule's concern doesn't apply. The accompanying comment captures this invariant well.

LGTM from my side. 👍

Looks good! Just one important comment IMO to avoid introducing two terms for the same concept.